The problem

Static reports are great, but you can only show so much data.

Accountability vs Reproducibility

The CUBI (pseudo)bulk RNA-seq ecosystem

seaPiper

• A GUI for the CUBI (pseudo)bulk RNA-seq pipelines
• Written in R and Shiny
• Uses the output CUBI pipeline
• Uses the CUBI R package ecosystem
• Uses the CUBI data ecosystem
• no analysis, only visualization and exploration

Why R/Shiny?

Shiny vs Dash

Basics of shiny

Simple code example for shiny:

library(shiny)
ui <- fluidPage(
  titlePanel("Hello Shiny!"),
  sidebarLayout(
    sidebarPanel(
      sliderInput("obs", "Number of observations:", min = 0, max = 1000, value = 500)
    ),
    mainPanel(
      plotOutput("distPlot")
    )
  )
)
server <- function(input, output) {
  output$distPlot <- renderPlot({
    hist(rnorm(input$obs))
  })
}
shinyApp(ui = ui, server = server)

Input and output

To access input and output, shiny provides the objects input and output in the server function. These are reactive objects, which means that they are automatically updated when their dependencies change or when the user interacts with the UI. Vice versa, they update their dependencies when they change.

Reactive expressions and variables

Reactive variables are created with reactive() or reactiveVal(). Also, input and output (available from the server function) are reactive.

Why debugging Shiny sucks

• most of the “interesting” code is run in anonymous functions / expressions

Therefore:

• you can’t use trace()
• tracebacks are useless
• finding out where the error is is annoying in large projects

Debugging Shiny T&T

What do I want for Christmas

How seaPiper works

Bioshmods - shiny modules for bioinformatics

• modular
• versatile
• extensible
• easy to implement
• well documented
• easy to debug

How R Shiny modules work

Shiny modules do what it says on the box: allow a modular approach to building shiny apps. A module gets its own ID (namespace) to avoid name clashes and uses it to create and access its UI elements.

Bioshmods example

library(shiny)
library(bioshmods)
data(C19)
ui <- fluidPage(
    geneBrowserTableUI("gb", 
      names(C19$contrasts))
)

server <- function(input, output) {
  geneBrowserTableServer("gb", 
    cntr=C19$contrasts,
    annot=C19$annotation)
}

shinyApp(ui, server)

Bioshmods example

geneBrowserTableServer

Communication between modules

Reactive expressions hold the state of the module:

• which data set was selected
• which contrast was selected
• which gene was clicked, etc.

When a reactive variable for communication is provided to a bioshmod module, it is automatically updated when the user interacts with the module.

Example: bioshmods

ui <- fluidPage(
         geneBrowserTableUI("gb", names(C19$contrasts)),
         textOutput("gene")
      )

server <- function(input, output) {
  gene_id <- reactiveValues()
  geneBrowserTableServer("gb", 
    gene_id = gene_id,
    cntr    = C19$contrasts,
    annot   = C19$annotation)
  output$gene <- 
    renderText(sprintf("gene ID: %s, data set: %s", 
      gene_id$id, gene_id$ds))
}

shinyApp(ui, server)

Example: bioshmods

Example: bioshmods

gene_browser <- function(x, primary_id="PrimaryID") {

  ui <- fluidPage(
    geneBrowserTableUI("geneTab", names(x$contrasts)),
    geneBrowserPlotUI("genePlot", contrasts=TRUE)
  )

  server <- function(input, output, session) {
    gene_id <- reactiveValues()
    geneBrowserTableServer("geneTab", 
      cntr=x$contrasts, 
      annot=x$annotation, 
      gene_id=gene_id,
      annot_linkout=annot_linkout)
    geneBrowserPlotServer("genePlot", 
      gene_id=gene_id, 
      covar=x$covariates, 
      exprs=x$expression, 
      annot=x$annotation)
  }

  shinyApp(ui, server)
}
gene_browser(C19)

What about accountability?

Main idea: rather then saving individual plots, save the exact code that generates them.

The code generated by bioshmods

df <- data.frame(C19$covariates, Expression=C19$expression["ENSG00000066279", , 
drop=TRUE])
colnames(df)[ncol(df)] <- "Expression"
ggplot(df, aes(x=group, y=Expression)) + 
geom_boxplot(outlier.shape = NA) + 
geom_jitter(size=3, alpha=.5, width=.1)

The most important things

• This is exactly the same code that is used to generate the graphics
• The variables are referenced from the parent environment - the caller of the module can use the chunk as is (e.g., to generate the report)

Under the hood

• A function constructs the code based on the module logic
• the constructed code references the variables in the parent environment (in the function that called the module server)
  • makes debugging actually somewhat easier - just paste the code into your terminal and run it
  • however, I am not sure whether this is a good idea in general (currently, it is possible to run it both ways)
• the same code is used to generate the graphics, the markdown chunk and the downloadable file

TODO